Surface contextual bandits, and match trackingCallback params to the SDK version - #113

DevTools derives its "latest SDK version" from the bundled SDK's
package.json, so a stale dependency means stale outdated-version
warnings. 1.7.0 also passes a userContext arg to instance-level
trackingCallbacks, which the arg forwarding in the previous commit
now preserves.

The row now reads "Found (3 params)" and the panel names the detected
signature, so the callback shape is visible without opening the page's
source.

Self-contained page for exercising the SDK tab with no GrowthBook
account: apiHost points at the same static server, and a static
api/features/local-test payload satisfies the canConnect probe.
?params=1|2|3|4 switches the trackingCallback arity and &ofu=1 supplies
an onFeatureUsage callback.

The SDK bundle is copied in by `yarn test-page` rather than vendored.

onFeatureUsage only ever lands in the SDK's user context, which core.ts
calls as cb(key, result); the 3-arg form is GrowthBookClient's global
context, which DevTools never patches. So the rest param was always
empty and the cast only silenced a type error for an argument that
cannot arrive.

trackingCallback genuinely does receive a third userContext arg in 1.7+,
so that forwarding stays - but now via a typed optional param rather
than a rest spread plus a cast.

- deferred tracking calls kept only {experiment, result}, but
  fireDeferredTrackingCalls replays them as
  trackingCallback(experiment, result, call.user), so a replayed
  3-param callback got user === undefined
- the wrapper discarded the callback's return value, so the SDK could
  no longer await an async trackingCallback
- a zero-arity forwarding wrapper parsed to [] and warned; that shape is
  common in minified analytics code and works fine
- parseCallbackParams desynced on brackets and commas inside string
  defaults, eg (experiment, result, sep = ",")
- the toString guard could throw a TypeError out of the injected script
  when a page shadowed toString to return a non-string
- the row read "Found (1 params)" and counted rest params, disagreeing
  with the detail panel

Also makes the bare-arrow test exercise the branch it names - a type
annotation forced parens, so deleting the branch left the suite green.

- parseCallbackParams no longer wraps toString in try/catch with a
  typeof guard; main never did and callers pass a real function
- trim multi-line comments down to one line each
- flatten the nested ternary behind the SDK tab row label
- straighten out the trackingCallback panel branches so each renders a
  whole sentence instead of splicing a conditional before the period
- drop the any casts from the tests

1.7.0 is where the SDK started calling the instance-level callback as
(experiment, result, userContext); through 1.6.5 it only ever passed
two args. So the expected arity is exact in both directions - two params
on 1.7.0+ silently drops the userContext payload, and three on anything
older leaves that param permanently undefined. Both now read as issues,
with a panel message naming the version and what is lost.

Stays lenient when the page's SDK version is unknown.

Contextual bandit rules keep their variations under contextualVariations
so pre-1.7 SDKs skip them, but getFeatureExperiments gated on
rule.variations - so they never reached the Experiments tab at all.
Read either field, then mark and explain the ones that are bandits.

- "Contextual Bandit" badge on the experiment row, the detail header,
  and matching exposure entries in Event Logs
- detail section with the weights actually applied to this user, as
  percentages to match Rule.tsx, and the attributes the matched context
  tested - both collapsible, since a bandit can have many of either
- calls out the three states that otherwise look like a healthy bandit:
  ref missing from the payload, no matching context, and not bucketed

Weights come from the feature's experimentResult: the SDK applies bandit
logic while evaluating the rule, so gb.run() and the raw rule never
carry them.

A live payload marks a contextual bandit rule with contextualVariations
alone: contextualBanditRef and the top-level contextualBandits block only
appear once the bandit has trained contexts. Keying detection off the ref
meant a real bandit rendered as an ordinary experiment.

Detection now keys off contextualVariations, and the detail panel handles
a bandit with no trained contexts by showing the rule's fallback weights
and saying that is what every user gets.

It sat just above Implementation, well below the fold, so a bandit read
as an ordinary experiment on open. It now follows Current value, and its
heading matches the label style of the sections around it.

- lead with a meta box: bandit ref, current leaf, bandit version
- "Variation Weights" replaces the fallback wording, and the assigned
  variation is emphasised in the bar list
- hide Targeting and Traffic for bandits, whose static rule weights
  contradict the dynamic ones shown above
- render context values directly rather than through ValueField

- ref, current leaf and version as a compact sub-line under the heading
- leaf shown as a pill beside the weights label when a context matched
- Setup block with the mockup's checks: whether trackingCallback receives
  userContext (bandit rewards can't be attributed without it) and whether
  a bandit definition is in the payload
- weights read "Weights for this context" when a context matched, and
  "Variation Weights" otherwise

- drop the unused getContextualBandit export and un-export the types and
  condition walker that nothing outside the module names
- cut multi-line explanatory comments down to one line each
- use clsx for the conditional weight-row classes, as elsewhere in the app
- cover the condition walker through getMatchedContextAttributes now that
  it is private

- evaluate bandit experiments from the feature result rather than run(),
  which skips the feature-rule path and so reports a variation the page
  is not serving
- read that result from the parent instead of mounting a third sandbox
  evaluation in the detail panel
- detect bandits in the logs via the runtime experiment's contextualBandit;
  the ref and contextualVariations are stripped by the time a log is built
- reuse ContextualBanditBadge in the experiments list and logs
- stop reporting an untrained bandit as a warning, and stop blaming the
  callback for a userContext an older SDK never passes
- say "Not applied for this user" when a definition exists but no bandit
  weights were used, rather than claiming the payload has none

For a bandit with no trained contexts the sub-line read "leaf: No trained
contexts yet", labelling a leaf that does not exist and repeating what the
setup check says. The leaf now only appears once weights were applied, and
a definition that exists but was not used is called out in the checks.

Radio cards stop being scannable once an experiment has more than a
handful of variations, which a bandit routinely does.

Also say what to do when a forced variation is hiding the bandit weights:
forcing sets hashUsed false, and the SDK then drops leafId and
variationWeights entirely.

The dropdown used position="popper", unlike every other Select in the
app; inside the fixed, scrolling detail panel its menu did not open.
Match the existing variant="soft" usage.

The leaf was buried in the grey sub-line and hard to find, so it now has
its own labelled row.

Without a value for the rule's hashAttribute the SDK logs "Skip because
missing hashAttribute" and returns no result at all, so the panel said
only that weights were not applied. It now names the attribute.

Selecting by value reads better than by index when the variations are
plain strings, as a bandit's usually are. Object-valued variations keep
the syntax-highlighted display, where a dropdown of JSON blobs would be
unreadable.

…the panel

Current value goes back to the read-only value display.

The variation dropdown rendered but would not open: the detail panel sets
z-index 1000 inline, and the portaled menu landed underneath it. Give the
menu content a higher z-index and keep popper positioning, which the nav
select already uses.

useGBSandboxEval stuffs rule metadata for its debug log, but when a rule
had no meta it substituted a single-element array however many variations
the rule had. The SDK indexes experiment.meta by variation index, so
getExperimentResult threw on any variation past the first, the whole
evaluate() call died, and every experiment then rendered as Inactive with
a null value - the bandit panel included.

Build the stuffed meta per variation, keeping any entries the rule already
had, and keep the single tag for rules with no variations since the debug
log reads meta[0].

…g lines

SelectField labels the selected value with the raw value, so the closed
dropdown read "1" rather than the variation name. Derive the name from the
index in formatOptionLabel, which covers the trigger and the menu.

Also stop echoing "In experiment" and "Force via dev tools" in the debug
box: the panel states both itself, right above it.

Both sections used a plain Text heading with the caret, which read as a
title rather than a toggle and sat tight against the row above. Use the
bold Link trigger and accordion my-4 spacing that SdkItemPanel already
uses for its collapsible sections.

Both accordion bodies started flush against the toggle.

Reverts the content margin from 180abd8: the gap belongs between the
previous section and the toggle, so each trigger now carries the top
margin.

Bandit experiments had an empty Results log: `banditResult ?? run()`
short-circuited run(), which is what populates the debug log. Always run,
and prefer the bandit result afterwards.

Remove the amber forced-variation warning, gated on `isForced && cb`,
which can never both be true - forcing sets hashUsed false and the SDK
then drops the weights that produce cb. The setup check already covers
that case with something actionable.

Gate the panel on the page's SDK version. DevTools evaluates with its own
bundled SDK, so on a pre-1.7 page it would report a bandit assignment the
page never made; say so instead.